<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="tutorial.css">
<TITLE>
Issues to be aware of when using bounded reals
</TITLE>
</HEAD>
<BODY >
<A HREF="tutorial064.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="tutorial063.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial066.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2 CLASS="section"><A NAME="htoc136">9.2</A>&nbsp;&nbsp;Issues to be aware of when using bounded reals</H2>
When working with bounded reals, some of the usual rules of arithmetic no
longer hold. In particular, it is not always possible to determine whether
one bounded real is larger, smaller, or the same as another. This is
because, if the intervals overlap, it is not possible to know the
relationship between the true values.<BR>
<BR>
An example of this can be seen in Figure&nbsp;<A HREF="#interval-compare">9.2</A>. If the
true value of <TT>X</TT> is <TT>X</TT><SUB>1</SUB>, then depending upon whether the
true value of <TT>Y</TT> is (say) <TT>Y</TT><SUB>1</SUB>, <TT>Y</TT><SUB>2</SUB> or
<TT>Y</TT><SUB>3</SUB>, we have <TT>X &gt; Y</TT>, <TT>X =:= Y</TT> or <TT>X &lt; Y</TT>,
respectively.

<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<DIV CLASS="center">
<IMG SRC="tutorial027.gif">
</DIV>
<BR>
<BR>
<DIV CLASS="center">Figure 9.2: Comparing two bounded reals</DIV><BR>
<BR>

<A NAME="interval-compare"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></BLOCKQUOTE>
Different classes of predicate deal with the undecidable cases in different
ways:<BR>
<BR>
<A NAME="@default228"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B>Arithmetic comparison</B><DD CLASS="dd-description"> (&lt;/2, =:=/2, etc.)
If the comparison cannot be determined definitively, the comparison succeeds
but a delayed goal is left behind, indicating that the result of the
computation is contingent on the relationship actually being true.
Examples:
<BLOCKQUOTE CLASS="quote"><PRE CLASS="verbatim">
?- X = 0.2__0.3, Y = 0.0__0.1, X &gt; Y.
X = 0.2__0.3
Y = 0.0__0.1
Yes

?- X = 0.2__0.3, Y = 0.0__0.1, X &lt; Y.
No

?- X = 0.0__0.1, Y = 0.0__0.1, X &lt; Y.
X = 0.0__0.1
Y = 0.0__0.1
Delayed goals:
        0.0__0.1 &lt; 0.0__0.1
Yes

?- X = Y, X = 0.0__0.1, X &lt; Y.
No
</PRE></BLOCKQUOTE><BR>
<BR>
<DT CLASS="dt-description"><B>Term equality or comparison</B><DD CLASS="dd-description"> (=/2, ==/2, compare/3, @&lt;/2, etc.)
These predicates consider bounded reals from a purely syntactic point of
view: they determine how the bounded reals compare syntactically, without
taking into account their meaning. Two bounded reals are considered equal
if and only if their bounds are syntactically the same (note that the
floating point numbers 0.0 and -0.0 are considered to be syntactically
different). A unique ordering is also defined between bounded reals which
do not have identical bounds; see the documentation for compare/3 for
details. This is important as it means predicates such as sort/2 behave in
a sensible fashion when they encounter bounded reals (in particular, they do
not throw exceptions or leave behind large numbers of meaningless delayed
goals) &mdash; though one does need to be careful when comparing or sorting
things of different types.
Examples:
<BLOCKQUOTE CLASS="quote"><PRE CLASS="verbatim">
?- X = 0.2__0.3, Y = 0.0__0.1, X == Y.
No

?- X = 0.0__0.1, Y = 0.0__0.1, X == Y.
X = 0.0__0.1
Y = 0.0__0.1
Yes

?- X = 0.2__0.3, Y = 0.0__0.1, compare(R, X, Y).
R = &gt;
X = 0.2__0.3
Y = 0.0__0.1
Yes

?- X = 0.1__3.0, Y = 0.2__0.3, compare(R, X, Y).
R = &lt;
X = 0.1__3.0
Y = 0.2__0.3
Yes

?- X = 0.0__0.1, Y = 0.0__0.1, compare(R, X, Y).
R = =
X = 0.0__0.1
Y = 0.0__0.1
Yes

?- sort([-5.0, 1.0__1.0], Sorted).
Sorted = [1.0__1.0, -5.0]       % 1.0__1.0 &gt; -5.0, but 1.0__1.0 @&lt; -5.0
Yes
</PRE></BLOCKQUOTE></DL>
Note that the potential undecidability of arithmetic comparisons has
implications when writing general code. For example, a common thing to do
is test the value of a number, with different code being executed depending
on whether or not it is above a certain threshold; e.g.


	<TABLE CELLPADDING=10>
<TR><TD BGCOLOR="#CCCCFF">
	<BLOCKQUOTE CLASS="quote"><PRE>
( X &gt;= 0 -&gt;
    % Code A
;
    % Code B
)
</PRE></BLOCKQUOTE></TD>
</TR></TABLE><BR>
When writing code such as the above, if <TT>X</TT> could be a bounded real,
one ought to decide what should happen if <TT>X</TT>'s bounds span the
threshold value. In the above example, if <TT>X = -0.1__0.1</TT> then a
delayed goal <TT>-0.1__0.1 &gt;= 0</TT> will be left behind and Code A
executed. If one does not want the delayed goal, one can instead write:<BR>
<BR>

	<TABLE CELLPADDING=10>
<TR><TD BGCOLOR="#CCCCFF">
	<BLOCKQUOTE CLASS="quote"><PRE>
( not X &gt;= 0 -&gt;
    % Code B
;
    % Code A
)
</PRE></BLOCKQUOTE></TD>
</TR></TABLE><BR>
The use of <TT>not</TT> ensures that any actions performed during the test
(in particular the set up of any delayed goals) are backtracked, regardless
of the outcome of the test.<BR>
<BR>
Finally, if one wishes Code B to be executed instead of Code A in the case
of an overlap, one can reverse the sense of the test:<BR>
<BR>

	<TABLE CELLPADDING=10>
<TR><TD BGCOLOR="#CCCCFF">
	<BLOCKQUOTE CLASS="quote"><PRE>
( not X &lt; 0 -&gt;
    % Code A
;
    % Code B
)
</PRE></BLOCKQUOTE></TD>
</TR></TABLE><BR>
<A NAME="@default229"></A><BR>
<HR>
<A HREF="tutorial064.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="tutorial063.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="tutorial066.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
